Using Overrides
This topic describes best practices for using the standard field size override feature on standard, content-driven forms (EForms and preprint forms). Changes, or overrides, to the default field size restrictions on standard content is permitted in cases where the desired layout of a form does not accommodate the field size defined on the same form. The same adjustments to custom content can be applied at the discretion of the author.
The Requirements Editor provides content authors with a means to modify the field size restrictions (width and vertical height) on a form and all instances of the document. These overrides allow you to construct a form that deviates from the standard data classification rules, or field definitions, found in the Single Source Tools application (http://nasrvtx95802/SingleSourceTools/DataClassifications/Default.aspx).
When considering using an override, the first option is to attempt to address content requirements through layout changes. If a layout change is not feasible, the override feature can be used to apply specified size values to a particular field on a form. In all cases, the use of overrides should be considered before creating new fields to accommodate size restrictions on certain forms.
| Do not use the override option when... | A layout change in the document can accommodate the content requirements. In this case, the field in question in the flow and context of the form does not present any space limitations and a layout change can address the issue. Layout changes are typically tested through a visual check of the output document (preview or test PDF). |
| Use the override option when... | A layout change on the form is not feasible AND space limitations prevent you from using the standard field definition, then authors may handle the requirements through an override to fit the layout design. |
In the Requirements Editor, field overrides are implemented through the Outline Editor perspective within the PTR Editor view. With the target field selected in the Outline Editor, locate the Class setting in the PTR Editor toolbar. You may need to click the drop-down arrow to show the Class setting along with some other setting options. You can then apply the override by entering a value for the desired field size to the Classattribute. You can only apply one classification attribute per data name (PublicName or GDDName) and the value supplied must be one of the existing data classifications documented in the Single Source Tools application. Data classification values are assigned to a public name (or GDDName) and typically include values such as DollarNN, TextNN, Initial, NumberNN, PercentNN, and so on. You will find these and other examples in the Single Source Tools application and guidance for each defined in the Wolters Kluwer Financial Services StyleGuide.
In this example, an override has been defined for the Name / Date signature fields in a signature section. The standard form required markup changes and modification to allow a two text changes. The signature line required a change from Name / Date to Lessee / Date Signed and Co-Lessee / Date Signed respectively. The standard data classification for the lessee (public name=Lessee.Signer.FullName) and co-lessee (public name=Lessee2.Signer.FullName) is defined as Text29 but in order to make the text change in the signature area we are going to override that value with a data classification of Text24 (lessee) and Text22 (co-lessee).
The field is assembled and the output generated consistent with the established override. In this example, the lessee and co-lessee values are now Text24 and Text22 respectively (an override of the default data classification value of Text29) to support the a width that allows the signature area text change to fit in the form layout.
After the override is applied, the signature area on the form looks like:
